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RObust Header Compression (ROHC): 
Requirements and Assumptions for O-byte IP/UDP/RTP Compression 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 


This document contains requirements for the O-byte IP/UDP/RTP 
(Internet Protocol/User Datagram Protocol/Real-Time Transport 
Protocol) header compression scheme to be developed by the Robust 
Header Compression (ROHC) Working Group. It also includes the basic 
assumptions for the typical link layers over which O-byte compression 
may be implemented, and assumptions about its usage in general. 


1. Introduction 


The goal of the Robust Header Compression (ROHC) Working Group is to 
develop header compression schemes that perform well over links with 
high error rates and long link roundtrip times. The schemes must 
perform well for cellular links, using technologies such as WCDMA, 
EDGE, and CDMA-2000. However, the schemes should also be applicable 
to other future link technologies with high loss and long roundtrip 
times. 


ROHC RTP has become a very efficient, robust and capable compression 
scheme, able to compress the IP/UDP/RTP headers down to a total size 
of only one octet. This makes ROHC RTP an excellent solution for 
future cellular environments with new air interfaces, such as WCDMA, 
making even speech services possible over IP with an insignificantly 
lower spectrum efficiency compared to existing circuit switched 
solutions. 


Jonsson Informational [Page 1] 


RFC 3243 Reqs and Assumptions for O-byte ROHC RTP April 2002 


However, all-IP cellular networks will also be built with already 
existing air interfaces such as GSM and IS-95, which are less 
flexible using radio bearers optimized for specific frame sizes 
matching the speech codecs used. This means that not a single octet 
of header can be added without switching to the next higher fixed 
packet size supported by the link, something which is obviously very 
costly. In the long term, this drawback should of course be 
eliminated with new, more flexible air interfaces, but in the short 
term it would be desirable if an efficiency comparable to the circuit 
switched case could also be achieved for already deployed speech 
codecs when used over the existing air interfaces. To achieve that, 
it must be possible to completely eliminate the headers for a 
majority of the packets during normal operation, and this is the 
purpose of O-byte header compression. All functionality normally 
provided by the l-octet header must then be provided by some other 
means, typically by utilizing functionality from the lower layer. It 
is important to remember that the purpose of O-byte header 
compression is to provide optimal efficiency for applications 
matching the link layer characteristics, not efficiency in general. 


As a starting point for these requirements, the well-established 
requirements base developed in the ROHC WG has been used. From that, 
the requirements have evolved through input from the 3GPP2 community 
and from discussions within the WG. 


2. Assumptions for the Applicability of O-byte RTP Header Compression 


The purpose of O-byte header compression is to provide optimal usage 
of certain links when the traffic pattern of a packet stream 
completely matches the characteristics of that link. There are no 
assumptions that only packet streams complying with that pattern will 
occur, but optimal efficiency cannot of course be provided when this 
is not the case. 


To make O-byte header compression feasible, it is assumed that lower 
layers can provide the necessary functionality needed to replace the 
1l-octet headers and fulfill the requirements defined in section 3. 
An example is the synchronized nature of most cellular links, which 
can provide sequencing and timing information and make packet loss 
detection possible. 


3. Requirements on O-byte RTP Header Compression 


Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of 
regular ROHC RTP compression [ROHC], these requirements are described 
as deltas to those defined in the regular RTP requirements [RTP-REQ]. 
For simplicity, this section is also separated into the same three 
subsections as the requirements in [RTP-REQ], where the first deals 
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with the impact of header compression on the rest of the Internet 
infrastructure, the second concerns the headers to be compressed, and 
the third covers efficiency and link technology related issues. 


3.1. Impact on Internet Infrastructure 


The meaning of header compression is in no way changed by the 
introduction of O-byte header compression. No additional impact on 
the Internet infrastructure is thus allowed. The "Transparency" and 
"Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also 
apply to O-byte RTP compression without any modifications. 


3.2. Supported Headers and Kinds of RTP Streams 


The O-byte RTP compression scheme in general imposes the same 
requirements on supported headers and RTP streams as regular ROHC RTP 
[RTP-REQ, section 2.2]. However, there are some aspects regarding 
the "Genericity" and IPSEC requirements that should be noted. 


The "Genericity" requirement of [RTP-REQ] states that compression of 
headers of arbitrary RTP streams must be supported, and this is also 
true for the O-byte compression scheme to the extent that it is not 
allowed to assume certain RTP behavior. However, as also stated in 
[RTP-REQ], this does not preclude optimizations for certain media 
types where the traffic pattern is known. For O-byte RTP, this means 
that the scheme must be able to handle arbitrary RTP streams in order 
to fulfill the requirements of section 3.1. However, due to the 
typical characteristics of O-byte compression, by requiring a traffic 
pattern that suits the link over which it is implemented to be able 
to compress down to O-byte headers, it becomes optimized for 
applications with link-suited traffic patterns. For traffic that 
does not comply with the link properties, the scheme must 
automatically and immediately fall back to non-O-byte RIP compression 
and must not have any impact on the packet stream. 


Regarding IPSEC, it should be noted that O-byte compression cannot be 
achieved if parts of the original headers are encrypted or carry 
randomly changing fields. IPSEC and O-byte RIP header compression 
therefore do not go well together. If IPSEC is used and prevents 0- 
byte compression, the scheme must fall back to a less efficient 
compression that can handle all present header fields. Of course, 
this applies not only to IPSEC but to all cases where headers cannot 
be compressed down to O-byte. 
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3s 


4. 


3. Performance Issues 


All the performance requirements of [RTP-REQ] also apply to 0-byte 
RTP header compression, with the following additions and exceptions: 


- Performance/Spectral Efficiency: For packet streams with traffic 
patterns that match the characteristics of the link over which 0- 
byte header compression is implemented, the performance should be 
such that 0-byte header packets are generated during normal 
operation, most of the time. 0-byte headers would then replace 
most of the l-octet headers used by regular ROHC RTP [ROHC]. 


Justification: Spectrum efficiency is a primary goal. Studies 
have shown that for certain applications and link technologies, 
even a single octet of header may result in a significant decrease 
in spectrum efficiency, compared to existing circuit switched 
solutions. 


- Header Compression Coexistence: The scheme must fit into the ROHC 
framework together with other ROHC profiles. 


Justification: Implementation simplicity is an important issue and 
the O-byte RTP compression scheme should therefore have as much as 
possible in common with the regular IP/UDP/RTP profile. 


- Unidirectional links: It is of less importance that the O-byte 
header compression scheme be able to also work over unidirectional 
links. 


Justification: O-byte header compression targets links that 
typically are bi-directional. 


IANA Considerations 
A protocol which meets these requirements, e.g., [LLA], will require 
the IANA to assign various numbers. This document by itself, 
however, does not require any IANA involvement. 

Security Considerations 
A protocol specified to meet these requirements, e.g., [LLA], may 


have a number of security aspects that need to be considered. This 
document by itself, however, does not add any security risks. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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